\subsection{Implementation}
%Challenges, solutions

\subsubsection{DataGenerator}
\textit{DataGenerator} class reads the input data set from a GraphML file, and creates the corresponding task set. For each task set it also creates the corresponding job sets. The computation time for each job is chosen randomly with an uniform distribution from the range from \textit{best case execution time}(BCET) to \textit{worst case execution time} (WCET). We use a uniform distribution because we want to model an average system behavior. By making a job running time close to BCET or WCET we would have another analysis tool instead.

The data generator sorts all the created jobs after 2 parameters: First according to their release time, so earliest release time comes first, and then according to their priority so highest priority comes first.

Furthermore the \textit{DataGenerator} class also computes the number of time units the simulation shall run. It gets the number of cycles as input (because the user knows how many time cycles he wants to run).


\subsubsection{Simulator}
The job queue is sorted after job release and thereafter after priority, so instead of copying the job queue to another array called ready list, we just skipped the ready list, and in each time unit cycle the job queue is only traversed until the release time is higher than the current time.

To be able to visualize the schedules produced by the \textit{Simulator}, we have added a graphics engine to the project: it uses the SVG Salamander graphics library \cite{SVG} to actually make an image and is designed to employ the composite design pattern \cite{COMPOSITE-DP}. The wish to visualize the computed schedule added the need for collecting information about when a job has execution time on the processor. Therefore for each job the time units where the job is executed is stored in an array.


\subsubsection{ResponseTimeAnalyzer}
As mentioned in the design section, the cases where a task set is only schedulable sometimes are computed as not schedulable. This is done by letting the \textit{computation time} be the worst case execution time.

Besides decide if a overall task set is executable, the \textit{ResponseTimeAnalyzer} also computes the worst case execution time for each task. The results are stored in an array. For tasks that are not executable the value $-1$ is stored to keep the order in the array.

% \subsubsection{SVG Engine}
% Our graphics engine: SVGSalamander SVG graphics library and Composite Design pattern used in our implementation.
% 
% It consist of the 5 classes:
% \begin{enumerate}
% 	\item \textit{GObject}: the main abstract graphics class.
% 	\item \textit{JobCanvas}: a canvas to display \textit{Job}.
% 	\item \textit{TaskCanvas}: a canvas to display \textit{Task} and all its jobs.
% 	\item \textit{Container}: a container for each {GObject} type object (Composite Design pattern).
% 	\item \textit{JobViewer}: a class to draw geometrical primitives e.g. lines, polygons etc.
% \end{enumerate}

\subsubsection{A3 - Scheduling to more than one processor using list scheduling}
For each task the scheduler needs to find the processor that allows earliest finish time of n. Since we don't take communication into account and since we assume that all processors works with the same speed (simplification), we only needs to consider which processor ) are first ready for the task.

We assume that the system is homogeneous (take same time to run on each proc    essor?) and therefore the execution time equals the computation cost of a no    de (Sinnen2005,2).

   When equal, which processor to choose?
     First: Most work on the first processor.
     Other: Spread out the work. More communication.

Dublication:
   Compute for each processor. Take into account: Com. til parent processor f    ra parents parents.
